A computer program being executed on a computer is known as a computer process and may simply be referred to as a process. Processes require mechanisms for exchanging data among them. These mechanisms are known as inter process communications mechanisms (IPCs). One category of IPC, known as sockets, was initially developed in the early 1980s at the university of California at Berkeley for use with computer systems utilizing the UNIX computer operating system. Sockets technology has since been adopted by many computer software and operating system developers including IBM.
Exponential increases in the use of computer networks and the expansion of public networks such as the Internet have resulted in a need for secure data communications. In response, Netscape Communications developed a secure IPC mechanism known as Secure Sockets Layer (SSL) (see U.S. Pat. No. 5,657,390). SSL is responsible for authenticating computer systems involved in the exchange of information and for encrypting and decrypting the data they exchange. SSL has been revised on at least two occasions and a derivative implementation, known as Transport Layer Security version 1 (“TLS”), is defined in Internet Engineering Task Force (“IETF”) Request for Comments (RFC) 2246.
SSL operates as an intermediary between an application process, such as a web browser, and a TCP/IP stack. TCP/IP is a combination of communications protocols used of route data over a data network and ensure its delivery. When a computer is enabled to transport data using TCP/IP the computer is referred to as having a TCP/IP stack. SSL sessions and SSL enabled processes exchange information messages using a predetermined message format known as SSL Application Programming Interface (“API”). The messages exchanged are referred to as API calls. Where several instances of SSL are simultaneously executed on a computer, each instance of SSL is referred to as an SSL session.
Because an SSL session is generally tied to the application process that requested its services and terminating an application process terminates the corresponding SSL session, individual processes requiring SSL services must initiate separate SSL sessions. Current SSL implementations generally require that an application process remain un-terminated until its SSL session has completed communications. As a consequence, available computer resources must be sufficient to maintain all un-terminated processes regardless of whether or not those processes are involved in active communications. Computer resources include processor time, volatile and non-volatile memory, and data throughput bandwidth.
In addition, SSL sessions encounter delays in receiving responses from computers with which they have been directed to communicate. These delays further extend the time application processes must continue executing. The result is an excessive drain of computer system resources. As the number of application processes, SSL sessions, and response delays grow, so does the danger of a computer system failing due to the depletion of available computer resources. These circumstances are often encountered in high-volume distributed computing environments including those with high numbers of concurrent transactions such as credit card transaction authorization systems. The possibility of computer system failure is heightened further where individual applications utilize multiple requesting processes or where computer systems execute multiple applications concurrently. While such concerns may be combated by strategies such as increasing overall data throughput at the TCP/IP transport level or increasing available computer resources, the present invention provides a solution that allows for the asynchronous reading of data across secure sockets layer (SSL) sessions and makes more efficient use of existing computer resources.